Methods of establishing virtual circuits and of providing a virtual private network service through a shared network, and provider edge device for such network

ABSTRACT

A virtual private network (VPN) service is provided through a shared network infrastructure comprising interconnected provider edge (PE) devices having customer edge (CE) interfaces. Some of the CE interfaces are allocated to a VPN supporting virtual LANs. A correspondence between a CE interface and a virtual LAN is learnt on the basis of tagged frames received at this CE interface and including an identifier of this virtual LAN. The learning process permits the detection of pairs of CE interfaces which correspond to a common virtual LAN. Upon such detection, a virtual circuit is established in the shared network infrastructure between the PE devices having these CE interfaces, and subsequently used for forwarding frames including the identifier of the common virtual VLAN.

BACKGROUND OF THE INVENTION

[0001] The present invention relates to the provision of virtual privatenetwork (VPN) services through carrier networks such as MetropolitanArea Networks (MANs) or Wide Area Networks (WANs).

[0002] A VPN emulates a private network over public or sharedinfrastructures. When the shared infrastructure is an IP network such asthe Internet, the VPN can be based on an IP tunneling mechanism, asdescribed in Request For Comments (RFC) 2764 published in February 2000by the Internet Engineering Task Force (IETF). Another approach, moreparticularly concerned by the present invention, provides link layerconnectivity for the devices affiliated to the VPN.

[0003] Traditional WAN data layer 2 services provided by carriers arebased on the virtual circuit concept. Data units are switched within thecarrier network along pre-established trails referred to as virtualcircuits. These data units are for instance packets in X.25 networks,frames in Frame Relay (FR) networks, cells in Asynchronous Transfer Mode(ATM) networks, . . . The carrier network may also have a Multi-ProtocolLabel Switching (MPLS) architecture built over an infrastructuresupporting a connectionless network layer protocol such as IP. MPLS isdescribed in RFC 3031 published in January 2001 by the IETF. The virtualcircuits within a MPLS network are referred to as Label Switched Paths(LSPs).

[0004] The virtual circuits can be pre-established by a configurationprocess, called “provisioning”, performed by the network operator: theyare then called Permanent Virtual Circuits (PVC). Alternatively, theycan be established dynamically on request from the customer equipment:they are then called Switched Virtual Circuits (SVC).

[0005] Providing a SVC service puts constraints on both the ProviderEdge (PE) and the Customer Edge (CE) devices. Both must support a commonsignaling set-up protocol such as, e.g., the ATM Q.2931 signalingprotocol for ATM switched networks. Signaling protocols are complex,they induce additional costs (equipment costs, operational costs . . . )and they may cause interoperability problems. Inadequate operation ofone CE may block a PE and hence interrupt the service for several othercustomers. Most of the time, higher-level protocols and applicationshave not been designed to properly drive such SVC signaling, and it isnecessary to develop sub-optimal emulation modes (for instance LANemulation, classical IP, . . . ). These issues can explain why SVCservices have been so seldom deployed for FR and ATM networks.

[0006] On the other hand, providing a PVC service requires an agreementbetween the provider and the customer regarding the endpoints of eachvirtual circuit. Then it requires provisioning of each virtual circuitby the provider. Often, it also requires additional provisioning by thecustomer in the CE device, unless some special signaling allows CEdevices to automatically discover the virtual circuits. In any case,these provisioning actions must be performed coherently between theprovider and his customers, and they are a potential source of problems.

[0007] Recently, several vendors have been promoting Ethernet as auniversal access media for LAN, MAN and WAN services. Several draftspresented at the IETF cover the way to signal and provision layer 2virtual private network (L2 VPN) services based on an IP/MPLSinfrastructure (see, e.g., Kompella et al., “MPLS-based Layer 2 VPNs”,Internet Draft, draftkompella-ppvpn-I2vpn-00.txt, published in June 2001by the IETF).

[0008] As specified in the IEEE standard 802.1Q approved in December1998, Ethernet networks may support one or more Virtual Local AreaNetworks (VLANs). An Ethernet frame circulating in such a network mayinclude, after the Medium Access Control (MAC) address, an additionalfield called tag header or Q-tag which contains a VLAN identifier (VID).Accordingly, a VLAN-aware Ethernet bridge has the ability to performframe switching based on the VID, deduced either from the physical portfrom which the incoming frame is received or from the contents of itstag header. A VLAN is used for the layer 2 broadcasting and forwardingof frames within a sub-group of users (subscribers of that VLAN). Forexample, in a corporation, it is possible to define respective virtualLANs for various departments to enable selective broadcasting andforwarding of information in the layer 2 procedures.

[0009] It has been suggested that the concept of VLAN can be extended inthe case where Ethernet traffic is transported over a MPLS network (see,e.g., Martini et al., “Transport of Layer 2 Frames Over MPLS”, InternetDraft, draft-martini-I2circuit-trans-mpls-07.txt, published in July 2001by the IETF).

[0010] In such a case, a specific MPLS virtual circuit, or LSP,originating at a PE can be associated with each VLAN to forward theframes intended for subscribers of that VLAN. The CE sends tagged framesto the PE and the latter switches them to the relevant virtual circuitsbased on the ingress physical port and the VID.

[0011] It should be noted that this port/VID switching mechanism willachieve the full functionality of a IEEE 802.1Q network on the conditionthat the different hosts pertaining to any given VLAN of a VPN are notlinked to the carrier network through more than two PE/CE interfaces.Otherwise, VLAN identification is not sufficient for the source PE todetermine which is the destination PE or CE, i.e. whether a virtualcircuit or physical port is to be used. When such constraint exists onthe VLAN topology, the VPN service provided by the carrier can bereferred to as a “virtual connection” or “point-to-multipoint” service.

[0012] Other types of VPN service do not rely on such port/VID switchingat the PEs. For example, a full VLAN service (supporting more than twoPE/CE interfaces per VLAN within a VPN) can be provided if the PEs arecapable of performing MAC address learning and switching, like anEthernet bridge. However, this is rather complex because the carrier hasto store and maintain tables at the PEs, for associating a virtualcircuit or physical port to any Ethernet MAC address found in a framecoming from the CE.

[0013] Because Ethernet media were designed from the beginning as a LANtechnology, they do not provide the signaling mechanisms required forWAN SVC networks. So establishing Ethernet PVC across a WAN networkrequires provisioning in both PE and CE devices.

[0014] An object of the present invention is to alleviate theseprovisioning issues.

[0015] Another object is to provide for dynamic establishment ofEthernet-like SVCs without any signaling between CE and PE devices.

[0016] Another object is to provide an Ethernet-like VPN service of thevirtual connection type without requiring changes in the CE devices.These devices should advantageously use regular Ethernet adapters, theupper layer protocols and applications remaining unchanged.

SUMMARY OF THE INVENTION

[0017] According to a first aspect, the invention proposes method ofestablishing a virtual circuit including at least one PE device for avirtual private network having a plurality of CE devices. This methodcomprises the steps of:

[0018] receiving, at a first said PE device, an indication from at leastone said CE device identifying a VLAN which includes said CE device; and

[0019] establishing, for each VLAN identified which includes a pluralityof CE devices in which at least one said CE device is connected to asecond PE device, a virtual circuit between said first and second PEdevices.

[0020] In another aspect of the invention, a VPN service can be providedthrough a shared network infrastructure comprising a plurality ofinterconnected PE devices having CE interfaces. Some of the CEinterfaces are allocated to a VPN supporting a plurality of VLANs andare arranged for exchanging tagged data frames with CE devicesrespectively connected to the PE devices through said CE interfaces,each tagged frame including a VLAN identifier. The method comprises thefollowing steps:

[0021] receiving at least one tagged frame from a CE device at each CEinterface allocated to said VPN, and learning a correspondence betweensaid CE interface and each VLAN identifier included in said at least onetagged frame;

[0022] detecting whether a pair of CE interfaces allocated to said VPNand belonging to two PE devices correspond to a common VLAN identifier;and

[0023] in response to such detection, establishing at least one virtualcircuit in the shared network infrastructure between the two PE devices,for forwarding frames including said common VLAN identifier.

[0024] The VPN typically has a topology such that at most two of itsallocated CE interfaces are allowed to receive tagged frames including agiven VLAN identifier. In this context, the invention provides a way toautomatically establish a set of point-to-multipoint connections in agiven VPN. Connection establishment is triggered by the data receivedfrom the customer equipment.

[0025] The PE device learns the VLAN-id in the frames received from thecustomer devices and automatically signals the establishment of perVLAN-id virtual circuits (VCs) between PE devices.

[0026] In a preferred embodiment of the invention, the VCs are labeledswitched paths of a MPLS architecture supported by the shared networkinfrastructure. A VC is then identified by a VC-label, which simplifiesthe provisioning and management on the PE device. However, other typesof carrier networks can be used to provide a L2 VPN service inaccordance with the invention, e.g. frame relay, ATM, X.25, etc.

[0027] The PE device looks at the VLAN-id (VID) of frames coming fromeach CE device. When a new VID is observed, the frame is preferablyflooded to every PE device concerned by the VPN, and then to every CEinterface allocated to that VPN. The ingress PE device learns, in a VLANlearning table that the source CE device is now using that VID. Theingress PE also signals to every other PE device a tuple (VC-label,VPN-id, VID) bound to the CE interface where that CE device isconnected. If another PE device in the shared network has a CE interfaceallocated to the same VPN and using the same VID, it will accept theVC-label, and signal back another VC-label with (VPN-id, VID), bound tothe latter CE interface. The VC is then established in both directions.

[0028] Such dynamic setup of VCs by means of VLAN information directlylearnt from customer data frames has the significant advantage ofrequiring no provisioning at the VC endpoints (PEs), in particular noconfiguration relating to the VID values. As a result, no agreement isrequired between customer and provider regarding VC endpoints locationsand addresses. The same dynamicity as a SVC call setup mechanism isachieved: the customer can have a new carrier VC set up at any time bystarting a new VLAN in two CE devices. No notification to the provideris required. There are also fewer risks to do provisioning errors. Inaddition, no specific signaling is required at the CE devices. A VC canbe automatically released by a PE device when not used, withoutrequiring upper layer action, in response to the observation that a CEdevice does not use a VID any more for a certain time.

[0029] Another aspect of the invention relates to a PE device comprisingmeans for communicating with other PE devices, at least one CEinterface, configuration means for allocating at least one CE interfaceto a VPN supporting a plurality of VLANs, means for mapping a VLAN to aCE interface allocated to the VPN, said VLAN being indicated in datareceived at said CE interface, means for identifying, in relation to theindicated VLAN, another PE device having a CE interface allocated to theVPN, and means for establishing a virtual circuit to the identified PEdevice.

[0030] Another aspect of the invention relates to a PE device suitablefor implementing the above method of providing a VPN service through ashared network infrastructure, comprising:

[0031] means for communicating with other PE devices through the sharednetwork infrastructure;

[0032] at least one local CE interface;

[0033] configuration means for allocating at least one local CEinterface to a VPN supporting a plurality of VLANs, the allocated localCE interface being arranged for exchanging tagged data frames with arespective CE device, each tagged frame including a VLAN identifier;

[0034] means for learning a correspondence between a first local CEinterface allocated to said VPN and a first VLAN identifier included inat least one tagged frame received from a CE device at said first localCE interface;

[0035] means for identifying another PE device having a CE interfaceallocated to said VPN and having received a tagged frame including saidfirst VLAN identifier; and

[0036] means for establishing a virtual circuit in the shared networkinfrastructure, for communicating frames including said first VLANidentifier with the identified PE device.

[0037] The preferred features of the above aspects which are indicatedby the dependent claims may be combined as appropriate, and may becombined with any of the above aspects of the invention, as would beapparent to a person skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

[0038] FIGS. 1-3 are diagrams of a simplified example of virtual privatenetworks making use of resources of a carrier network.

[0039]FIG. 4 is a block diagram of a provider edge device according tothe invention.

[0040]FIG. 5 is a flow chart of a frame handling procedure which can beused in the provider edge device of FIG. 4 in an embodiment of theinvention.

DESCRIPTION OF PREFERRED EMBODIMENTS

[0041] The invention is illustrated here in its currently preferredapplication to a VPN service of the Ethernet type using a MPLS-basedcarrier infrastructure. It will be appreciated that it can also beapplied to other types of customer and/or provider networks.

[0042] The carrier network 10 shown in FIGS. 1-3 is for instance an IPnetwork having routers supporting the MPLS architecture. Some of theserouters 11 are label edge routers (LERs) adapted to form PE devices forthe provision of the L2 VPN service. They are denoted PE-1 to PE-3 inthe diagram of FIGS. 1-3. Other routers (not shown) of the carriernetwork 10 are label-switched routers (LSRs) which link the LERs by afull mesh of logical links (transport tunnels).

[0043] Each PE device 11 is initially configured by the provider withthe list of the IP addresses of all the remote PE devices. Each PEdevice then establishes a transport LSP to each remote PE. This can bedone through any signaling protocol suitable to set up LSPs, such as LDP(Label Distribution Protocol, see RFC 3036 published in January 2001 bythe IETF), RSVP (Resource reSerVation Protocol, see RFC 2205 publishedin September 1997 by the IETF), etc. LDP will be more particularlyconsidered in the following.

[0044] FIGS. 1-3 also show customer edge devices 12 that are eachconnected to a respective CE port of a PE device 11. These CE devices 12are denoted CE-A to CE-E, with CE-A and CE-B connected to PE-1, CE-Cconnected to PE-2, and CE-D and CE-E connected to PE-3. We assume herethat the CE devices are supporting VLANs and are using tagged trafficcompliant with the IEEE 802.1Q standard. Untagged traffic is assigned tothe default VID=0. We also assume that at most two CEs per VPN areallowed to use a same VLAN identifier.

[0045]FIG. 4 shows the CE interfaces 20 of a PE device 11, as well asits IP/MPLS interface 21 by which it is connected to one or more LSR ofthe carrier network. A control and switching module 22 cooperating withthese interfaces 20, 21 is programmed to implement the VPN service asexplained hereafter.

[0046] In each PE device, the service provider configures the VPN-id ofeach CE interface, or port, offering a L2 VPN service. Each local portnumber is then allocated to one VPN-id.

[0047] After this configuration step, each PE device 11 distributes VClabels per VPN to the other PE devices. This can be signaled throughLDP. These VC-labels per VPN will be used to flood frames within a VPN.The corresponding LSPs, established between each pair of PE deviceshaving at least one CE port allocated to a given VPN, can thus bereferred to as flooding VCs.

[0048] Once these flooding VCs have been established, the L2 VPN servicecan be started. No additional configuration will be needed in thecarrier network.

[0049]FIG. 1 shows an example with two customer VPNs, having VPN-id=xand VPN-id=y. VPN x includes CE devices CE-A, CE-C and CE-D. VPN yincludes CE devices CE-B and CE-E. The dashed lines illustrate theflooding VCs established for VPN x, while the dash-and-dot linesillustrate the flooding VCs established for VPN y.

[0050] The distribution of the VLANs is then learnt at the PE devicesbased on the VIDs included in the tagged frames received from the CEdevices.

[0051] In each PE, the control and switching module 22 learns a lookuptable T which is subsequently used to retrieve the VCs and CE portscorresponding to the different VLANs of a VPN. An entry in table T has aVPN-id and a VID corresponding to a VLAN, and identifies communicationresources in association therewith. These communication resources can betwo local CE port numbers if the VLAN has its two CE devices connectedto the same PE device. If the VLAN has a CE device connected to a localport and another CE device connected to a remote PE device, theresources stored in table T comprise a local CE port number and a VCestablished in the carrier networks, with a VC label for sending framesto the remote PE and another VC label for receiving frames from theremote PE.

[0052]FIG. 2 shows an exemplary distribution of VLAN identifiers whichmay be found in the frames received at the CE ports in the configurationof FIG. 1 (in this example, there is one CE device for (VPN-id, VID)=(x,2), (y, 7) or (y, 9), and two CE devices for (VPN-id, VID)=(x, 3), (x,5) or (y, 3)).

[0053]FIG. 3 shows the corresponding VCs to be established in thecarrier network: VC 13 x between PE-1 and PE-3 for communication oftagged frames of VPN x with VID=3 between CE-A and CE-D; VC 14 x betweenPE-2 and PE-3 for communication of tagged frames of VPN x with VID=5between CE-C and CE-D; and VC 13 y between PE-1 and PE-3 forcommunication of tagged frames of VPN y with VID=3 between CE-A andCE-E. The corresponding content of table T in PE-1 is shown in FIG. 4where 13 x 1 and 13 x 2 (13 y 1 and 13 y 2) denote the VC-labels used inthe two directions on VC 13 x (13 y).

[0054]FIG. 5 illustrates a procedure which may be used by the controland switching module 22 of a PE device to process an Ethernet framereceived by that PE device.

[0055] When the frame is received at a local CE port (yes in tests 30and 31), the corresponding VPN-id is retrieved in step 32 based on theconfiguration of the port number, and the VLAN identifier is read in thetag header of the frame in step 33. If table T contains no other localport number and no VC label for forwarding the frame (no in tests 34 and35), then the frame is propagated to all the other PE devices in step 36by pushing the labels of the flooding LSPs previously established. Inthis step 36, the frame is also propagated to any other local CE port ofthe PE device which has been configured for the VPN-id retrieved in step32. The PE device also allocates a VC label to the (VPN-id, VID) pair inview of the reception of frames through the carrier network, and storesit in table T (step 37). In step 38, the allocated VC label is sent,along with VPN-id and VID, to all the other PEs configured for the VPN.This can be done by means of a LDP message (see the Internet Draft“draft-martini-I2circuit-trans-mpis-07.txt”). An entry is created intable T in step 39 to learn the relationship between the CE port numberand the (VPN-id, VID) pair. The PE device can then wait for the nextEthernet frame (return to test 30).

[0056] A PE device receiving such LDP signaling message stores theindicated VC label in its table T in view of forwarding any frame of theidentified VPN coming from one of its local CE ports with the same VIDin the tag header. When such a frame is received from a local CE port, aVC label is already stored in table T for the relevant (VPN-id, VID)pair, so that test 35 is positive. The frame is thus forwarded on the VCin step 40 by pushing the VC label retrieved from table T. If it is thefirst frame received with that VID on that local CE port, the latter hasnot yet been learnt (test 41 is negative): it is then detected that twoCE ports correspond to the relevant (VPN-id, VID) pair. It is necessaryto allocate a VC label for the other direction and to send it back byLDP signaling. This is done in the above-described steps 37 and 38(except that in step 38 the LDP message is a response to the previousLDP message and can thus be sent only to the PE from which it came). Therelationship between the local CE port number and the (VPN-id, VID) pairis finally learnt in step 39. When test 41 is positive, nothing elseneed to be done since the VC is already established.

[0057] If test 34 is positive, the VLAN has its two CE devices connectedto the same PE device. The incoming frame is then forwarded to the otherrelevant local CE port identified by means of table T (step 42). If theport number of the incoming frame has already been learnt (test 43positive), the procedure returns to test 30 to wait for the next frame.If it has not yet been learnt, this is done in step 39 before returningto test 30.

[0058] The right part of FIG. 5 deals with the reception of Ethernetframe at a PE device through the carrier network (test 31 negative).

[0059] If the frame was received over a flooding LSP from another PE(test 45 positive), the popped VC label of that flooding LSP enables theretrieval of the VPN-id in step 46. The frame is then propagated by thePE device to each local CE port configured for the retrieved VPN-id(step 47), and the PE waits for a responding frame.

[0060] If the frame was received over a unicast VC, the VPN-id and theVID are retrieved in table T by means of the popped VC label of thatunicast LSP (step 48), as well as the corresponding local port number(step 49). The frame is then forwarded to that local CE port in step 50.

[0061] In practice, the learning stage will normally be very quick.Typically, the first frame received at a PE for a VPN/VLAN will be carrya SYN segment of the transmission control protocol (TCP). This firstframe will be forwarded to the other PEs configured for the VPN, alongwith the VC label distribution (path 30-31-32-33-34-35-36-37-38-39 inFIG. 5), and from there to the various CE devices of the VPN (path30-31-45-46-47). One of them will obtain a response carrying the TCP SYNACK segment which will be forwarded back to the first PE whiledistributing the VC label for the other direction (path30-31-32-33-34-35-40-41-37-38-39). The learning and signaling operationsare then finished for the VC. The first PE simply forwards the responseframe to the source CE device (path 30-31-45-48-49-50).

[0062] An entry of the lookup table T may become obsolete if a CE devicedoes not use a VID any more for a period of time. This is easilydetected at the PE by means of a timer. When it happens, the PE devicemay simply delete the entry. This is equivalent to a VC disconnectionprocedure.

[0063] A PE device may further be programmed to generate an alarmwhenever it detects that more than two CE interfaces transport usertraffic pertaining to the same VLAN. This would typically occur whenmore than one LDP response messages are received for a (VPN-id, VID)pair at the PE that first sent a LDP message for that pair (step 38).Such alarm indicates that the customer has not complied with the VLANtopology for which the VPN operates.

[0064] The text of the abstract repeated below is hereby deemedincorporated in the description:

[0065] A VPN service is provided through a shared network infrastructurecomprising interconnected PE devices having CE interfaces. Some of theCE interfaces are allocated to a VPN supporting virtual LANs. Acorrespondence between a CE interface and a virtual LAN is learnt on thebasis of tagged frames received at this CE interface and including anidentifier of this virtual LAN. The learning process permits thedetection of pairs of CE interfaces which correspond to a common virtualLAN. Upon such detection, a virtual circuit is established in the sharednetwork infrastructure between the PE devices having these CEinterfaces, and subsequently used for forwarding frames including theidentifier of the common virtual VLAN.

We claim:
 1. A method of establishing a virtual circuit including atleast one provider edge (PE) device for a virtual private network havinga plurality of customer edge (CE) devices, the method comprising thesteps of: receiving, at a first said PE device, an indication from atleast one said CE device identifying a virtual LAN (VLAN) which includessaid CE device; and establishing, for each VLAN identified whichincludes a plurality of CE devices in which at least one said CE deviceis connected to a second PE device, a virtual circuit between said firstand second PE devices.
 2. A method as claimed in claim 1, wherein thevirtual circuit includes a plurality of PE devices belonging to a sharednetwork infrastructure through which the virtual private network isprovided.
 3. A method as claimed in claim 1, wherein the virtual privatenetwork supports a plurality of VLANs, and wherein each CE device isconnected to a respective PE device by an interface arranged forexchanging data frames each including a VLAN identifier.
 4. A method asclaimed in claim 3, wherein the indication received from a CE device andidentifying a VLAN comprises a data frame including the identifier ofsaid VLAN.
 5. A method as claimed in claim 4, wherein said virtualcircuit is established for forwarding frames including said VLANidentifier.
 6. A method as claimed in claim 1, further comprising thesteps of: establishing a respective flooding virtual circuit in theshared network infrastructure between each pair of PE devices having atleast one CE interface connected to a CE device of the VPN; in responseto reception of a first frame including a VLAN identifier at a first CEinterface of a first PE device, propagating said first frame on eachflooding virtual circuit established from the first PE device; and inresponse to reception of the first frame on a flooding virtual circuitat another PE device, propagating the first frame to each CE device ofthe VPN connected to said other PE device.
 7. A method as claimed inclaim 6, further comprising the following steps in response to thereception of the first frame including said VLAN identifier at the firstCE interface: allocating, at the first PE device, a first virtualcircuit resource for the VLAN identifier included in the first frame;transmitting a first signaling message from the first PE device to eachother PE device having at least one CE interface connected to a CEdevice of VPN, said first signaling message indicating the first virtualcircuit resource and the VLAN identifier; and in response to receptionof the first signaling message at each other PE device, storing anidentification of the first virtual circuit resource in association withthe VPN and VLAN identifier.
 8. A method as claimed in claim 7, furthercomprising the following steps in response to reception of a secondframe including said VLAN identifier at a second CE interface, connectedto a CE device of said VPN, of the second PE device, whereby it isdetected that the first and second CE interfaces both correspond to saidVLAN identifier: allocating, at the second PE device, a second virtualcircuit resource for the VLAN identifier; and transmitting a secondsignaling message from the second PE device to the first PE device,thereby completing the establishment of a virtual circuit, defined bysaid first and second virtual circuit resource.
 9. A method as claimedin claim 8, wherein frames pertaining to the VPN and including said VLANidentifier are forwarded from the first PE device to the second PEdevice by means of the second virtual circuit resource, and framespertaining to said VPN and including said VLAN identifier are forwardedfrom the second PE device to the first PE device by means of the firstvirtual circuit resource.
 10. A method as claimed in claim 8, whereinthe first and second virtual circuit resources are labels of amulti-protocol label switching architecture.
 11. A method as claimed inclaim 10, wherein the first and second signaling messages are inaccordance with a label distribution protocol supported by themulti-protocol label switching architecture.
 12. A method as claimed inclaim 8, further comprising the step of forwarding the second frame tothe first PE device by means of the first virtual circuit resource. 13.A method as claimed in claim 11, wherein said second frame is forwardedby the first PE device through the first CE interface, identified ascorresponding to the VLAN identifier for which the first virtual circuitresource has been allocated.
 14. A method as claimed in claim 1, whereinthe VPN has a topology such that at most two CE devices thereof areallowed to communicate frames including a given VLAN identifier.
 15. Amethod as claimed in claim 1, wherein each CE device is connected to arespective PE device through an Ethernet interface.
 16. A method asclaimed in claim 1, wherein said virtual circuit is a label-switchedpath of a multi-protocol label switching architecture of a networkinfrastructure interconnecting a plurality of PE devices.
 17. A methodas claimed in claim 16, wherein the step of establishing a virtualcircuit comprises exchanging messages of a label distribution protocolsupported by the multi-protocol label switching architecture betweensaid first and second PE devices.
 18. A method as claimed in claim 1,wherein said first and second PE devices are distant devicescommunicating through a shared network infrastructure.
 19. A method asclaimed in claim 1, wherein said first and second PE devices arecollocated in a provider equipment.
 20. A method of providing a virtualprivate network (VPN) service through a shared network infrastructurecomprising a plurality of interconnected provider edge (PE) deviceshaving customer edge (CE) interfaces, wherein some of the CE interfacesare allocated to a VPN supporting a plurality of virtual local areanetworks (VLANs) and are arranged for exchanging tagged data frames withCE devices respectively connected to the PE devices through said CEinterfaces, each tagged frame including a VLAN identifier, the methodcomprising the following steps: receiving at least one tagged frame froma CE device at each CE interface allocated to said VPN, and learning acorrespondence between said CE interface and each VLAN identifierincluded in said at least one tagged frame; detecting whether a pair ofCE interfaces allocated to said VPN and belonging to two PE devicescorrespond to a common VLAN identifier; and in response to suchdetection, establishing at least one virtual circuit in the sharednetwork infrastructure between said two PE devices, for forwardingframes including said common VLAN identifier.
 21. A method as claimed inclaim 20, further comprising the following steps: establishing arespective flooding virtual circuit in the shared network infrastructurebetween each pair of PE devices having at least one CE interfaceallocated to said VPN; in response to reception of a first tagged frameincluding a VLAN identifier at a first CE interface, allocated to saidVPN, of a first PE device, propagating said first tagged frame on eachflooding virtual circuit established from the first PE device; and inresponse to reception of the first tagged frame on a flooding virtualcircuit at another PE device, propagating the first tagged frame to eachCE interface, allocated to said VPN, of said other PE device.
 22. Amethod as claimed in claim 21, wherein the correspondence between thefirst CE interface and the VLAN identifier is learnt in response to thereception of the first tagged frame including said VLAN identifier atthe first CE interface.
 23. A method as claimed in claim 21, furthercomprising the following steps in response to the reception of the firsttagged frame including said VLAN identifier at the first CE interface:allocating, at the first PE device, a first virtual circuit resource forsaid VPN and the VLAN identifier included in the first tagged frame;transmitting a first signaling message from the first PE device to eachother PE device of the shared network infrastructure having at least oneCE interface allocated to said VPN, said first signaling messageindicating the first virtual circuit resource and said VPN and VLANidentifier; and in response to reception of the first signaling messageat each other PE device, storing an identification of the first virtualcircuit resource in association with said VPN and VLAN identifier.
 24. Amethod as claimed in claim 23, further comprising the following steps inresponse to reception of a second tagged frame including said VLANidentifier at a second CE interface, allocated to said VPN, of anotherPE device, whereby it is detected that the first and second CEinterfaces both correspond to said VLAN identifier: allocating, at saidother PE device, a second virtual circuit resource for said VPN and saidVLAN identifier; and transmitting a second signaling message from saidother PE device to the first PE device, thereby completing theestablishment of a virtual circuit, defined by said first and secondvirtual circuit resource.
 25. A method as claimed in claim 24, whereinframes pertaining to said VPN and including said VLAN identifier areforwarded from the first PE device to said other PE device by means ofthe second virtual circuit resource, and frames pertaining to said VPNand including said VLAN identifier are forwarded from said other PEdevice to the first PE device by means of the first virtual circuitresource.
 26. A method as claimed in claim 24, wherein the first andsecond virtual circuit resources are labels of a multi-protocol labelswitching architecture of the shared network infrastructure.
 27. Amethod as claimed in claim 26, wherein the first and second signalingmessages are in accordance with a label distribution protocol supportedby the multi-protocol label switching architecture.
 28. A method asclaimed in claim 24, further comprising the step of forwarding thesecond tagged frame to the first PE device by means of the first virtualcircuit resource.
 29. A method as claimed in claim 28, wherein saidsecond tagged frame is forwarded by the first PE device through thefirst CE interface, identified as corresponding to the VLAN identifierfor which the first virtual circuit resource has been allocated.
 30. Amethod as claimed in claim 20, wherein the VPN has a topology such thatat most two CE interfaces allocated thereto are allowed to receivetagged frames including a given VLAN identifier.
 31. A method as claimedin claim 20, wherein the CE interfaces allocated to the VPN are Ethernetinterfaces.
 32. A method as claimed in claim 20, wherein said virtualcircuits are label-switched paths of a multi-protocol label switchingarchitecture of the shared network infrastructure.
 33. A method asclaimed in claim 32, wherein the step of establishing a virtual circuitbetween two PE devices comprises exchanging messages of a labeldistribution protocol supported by the multi-protocol label switchingarchitecture between said two PE devices.
 34. A provider edge (PE)device, comprising: means for communicating with other PE devices; atleast one customer edge (CE) interface; configuration means forallocating at least one CE interface to a virtual private network (VPN)supporting a plurality of virtual local area networks (VLANs); means formapping a VLAN to a CE interface allocated to the VPN, said VLAN beingindicated in data received at said CE interface; means for identifying,in relation to the indicated VLAN, another PE device having a CEinterface allocated to the VPN; and means for establishing a virtualcircuit to the identified PE device.
 35. A device as claimed in claim34, wherein the means for communicating with other PE devices comprise anetwork interface with a shared network infrastructure.
 36. A device asclaimed in claim 34, wherein each CE interface allocated to the VPN isarranged for exchanging data frames with a respective CE device, eachframe including a VLAN identifier.
 37. A device as claimed in claim 36,wherein the mapped VLAN is indicated by a VLAN identifier contained inat least one frame received from a CE device connected to said CEinterface.
 38. A device as claimed in claim 37, wherein the other PEdevice identified in relation to the indicated VLAN is a PE devicehaving received a frame including the said VLAN identifier
 39. A deviceas claimed in claim 38, wherein the means for communicating with otherPE devices comprise a network interface with a shared networkinfrastructure, and wherein the virtual circuit is established forcommunicating frames including the indicated VLAN identifier with theidentified PE device.
 40. A device as claimed in claim 35, furthercomprising: means for establishing respective flooding virtual circuitsin the shared network infrastructure to a plurality of other PE devicesconfigured to have at least one CE interface allocated to the VPN; andmeans responsive to reception of a data frame indicating said VLAN atsaid CE interface, for propagating said data frame on each of theflooding virtual circuits established to the other PE devices.
 41. Adevice as claimed in claim 40, further comprising: means responsive toreception, on a flooding virtual circuit from another PE deviceconfigured to have at least one CE interface allocated to the VPN, of asecond data frame indicating a VLAN not mapped to any CE interface, forpropagating the second data frame through any CE interface allocated tothe VPN.
 42. A device as claimed in claim 40, wherein the mapping meansare arranged to map said VLAN to said CE interface in response to thereception of the first data frame indicating said VLAN at said CEinterface.
 43. A device as claimed in claim 40, further comprising:means for allocating a first virtual circuit resource for the VPN andthe indicated VLAN in response to reception of a first data frameindicating said VLAN at said CE interface; means for transmitting toeach other PE device a first signaling message indicating the firstvirtual circuit resource and said VPN and VLAN.
 44. A device as claimedin claim 43, wherein the means for identifying another PE device areresponsive to reception from said other PE device of a second signalingmessage indicating a second virtual circuit resource and said VPN andVLAN, whereby frames indicating said VLAN and received at said CEinterface are forwarded to the identified PE device on a virtual circuitby means of the second virtual circuit resource.
 45. A device as claimedin claim 44, wherein the first and second virtual circuit resources arelabels of a multi-protocol label switching architecture. 46 A device asclaimed in claim 45, wherein the first and second signaling messages arein accordance with a label distribution protocol supported by themulti-protocol label switching architecture.
 47. A device as claimed inclaim 34, wherein the VPN has a topology such that at most two CEinterfaces allocated thereto are allowed to receive data framesindicating a given VLAN.
 48. A device as claimed in claim 34, whereineach CE interface allocated to the VPN is an Ethernet interface.
 49. Aprovider edge (PE) device for a shared network infrastructure,comprising: means for communicating with other PE devices through theshared network infrastructure; at least one local customer edge (CE)interface; configuration means for allocating at least one local CEinterface to a virtual private network (VPN) supporting a plurality ofvirtual local area networks (VLANs), the allocated local CE interfacebeing arranged for exchanging tagged data frames with a respective CEdevice, each tagged frame including a VLAN identifier; means forlearning a correspondence between a first local CE interface allocatedto said VPN and a first VLAN identifier included in at least one taggedframe received from a CE device at said first local CE interface; meansfor identifying another PE device having a CE interface allocated tosaid VPN and having received a tagged frame including said first VLANidentifier; and means for establishing a virtual circuit in the sharednetwork infrastructure, for communicating frames including said firstVLAN identifier with the identified PE device.
 50. A device as claimedin claim 49, further comprising: means for establishing a respectiveflooding virtual circuit in the shared network infrastructure to eachother PE device configured to have at least one CE interface allocatedto said VPN; and means responsive to reception of a first tagged frameincluding the first VLAN identifier at the first local CE interface, forpropagating said first tagged frame on each of the flooding virtualcircuits established to said other PE devices.
 51. A device as claimedin claim 50, further comprising: means responsive to reception, on aflooding virtual circuit from another PE device configured to have atleast one CE interface allocated to said VPN, of a tagged frameincluding a VLAN identifier for which no CE interface has been learnt,for propagating said tagged frame through any local CE interfaceallocated to said VPN.
 52. A device as claimed in claim 50, wherein thelearning means are arranged to store the correspondence between thefirst local CE interface and the first VLAN identifier in response tothe reception of the first tagged frame at the first local CE interface.53. A device as claimed in claim 50, further comprising: means forallocating a first virtual circuit resource for said VPN and first VLANidentifier in response to the reception of the first tagged frame at thefirst local CE interface; means for transmitting a first signalingmessage to each other PE device of the shared network infrastructureconfigured to have at least one CE interface allocated to said VPN, saidfirst signaling message indicating the first virtual circuit resourceand said VPN and first VLAN identifier.
 54. A device as claimed in claim53, wherein the means for identifying another PE device are responsiveto reception from said other PE device of a second signaling messageindicating a second virtual circuit resource, said VPN and first VLANidentifier, whereby frames including said first VLAN identifier andreceived at the first CE interface are forwarded to the identified PEdevice on a virtual circuit by means of the second virtual circuitresource.
 55. A device as claimed in claim 54, wherein the first andsecond virtual circuit resources are labels of a multi-protocol labelswitching architecture of the shared network infrastructure.
 56. Adevice as claimed in claim 55, wherein the first and second signalingmessages are in accordance with a label distribution protocol supportedby the multi-protocol label switching architecture.
 57. A device asclaimed in claim 49, wherein the VPN has a topology such that at mosttwo CE interfaces allocated thereto are allowed to receive tagged framesincluding a given VLAN identifier.
 58. A device as claimed in claim 49,wherein each CE interface allocated to said VPN is an Ethernetinterface.